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(57) Abstract: A method and apparatus for managing cryptographic keys using URL (Uniform Resource Locator) programming 
interface (UPI) is described. A user of public key, symmetric, or other cryptographic scheme must maintain one or more keys, a list 
of trusted certificate authorities, and a database of certificates. This collection of items is called a data vault. Applications, including 
Web browsers, use different standards, algorithms, and formats to store and manage cryptographic keys. The claimed invention 
provides a single data vault that is accessible by any HTTP-capable application. The data vault may reside on any form. of storage 
including a disk file, a directory, a Smart Card, a desktop computer, a handheld device, or other similar devices. A data vault may 
also extend over numerous combinations of storage devices. This architecture, in one embodiment of the invention, provides a data 
vault as a very small HTTP stack. This minimal stack may be installed on a variety of devices to permit secure Internet access to and 
from any HTTP-capable device. 
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METHOD AND APPARATUS FOR CRYPTOGRAPHIC KEY 
MANAGEMENT USING URL PROGRAMMING INTERFACE 



BACKGROUND OF THE INVENTION 

5 ' . - • • 

FIELD OF THE INVENTION 

This invention relates to. the field of computer systems, and, more 
specifically, managing cryptographic keys using URL (Uniform Resource 
10 Locator) programming interface (UPI). 

Portions of the disclosure of this patent document contain material that is 
subject to copyright protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the. patent document or the patent 

15 disclosure as it appears in the Patent and Trademark Office file or records, but 
otherwise reserves all copyright rights whatsoever. 

Sun, Sim Microsystems, the Sim logo, Java™ and all Java-based 
trademarks and logos are trademarks or registered trademarks of Sam 
Microsystems, Inc. in the United States and other countries. All SPARC™ 

20 trademarks are used under license and are trademarks of SPARC International, 
Inc. in the United States and other countries. Products bearing SPARC™ 
trademarks are based upon an architecture developed by Sun Microsystems, Inc. 

BACKGROUND ART 

25 

Secure network access to files, processes and devices poses many 
challenges to application programmers. A lack of standards creates a multitude 
of interfaces to security modules. Many World Wide Web (Web) browser 
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programs use different cryptographic systems and algorithms, providing 
complex interface requirements for Web applications. 

Users of network security in the current technology face challenges as 
5 well. A user with multiple network access devices will invariably have a plethora 
of security data to manage across these devices. Access devices, for example, 
personal computers, hand-held computers, laptop computers, wireless Web 
devices and networked office systems, will often use different cryptographic 
schemes to identify a user to the network. 

10 

Unf ortunately, cryptographic data is difficult to transfer between access 
devices. If the user wishes to send or receive encrypted data or messages the 
user will likely maintain cryptographic "key" data on each of these devices. 

15 Additionally, a user of digital signatures must maintain one or more sets 

of digital certificates from a digital certificate authority that authenticates the 
user's digital signature. Data such as cryptographic keys, trusted certificates and 
a database of digital certificates stored in one physical location will be referred to 
herein as cryptographic data, or as a data vault. A data vault resides on one or 

20 more portable storage mediums and contains distinct elements of cryptographic 
data. Each cryptographic element of the data vault is stored separately and is 
individually addressable. 

Secure Network Application 

Using current technology, writing application programs requiring secure 
access to devices such as home automation, home networks, or realtime process 
control devices, is also a challenge. Every device has its own communication 
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protocol and security considerations, which an application programmer must 
understand and work with in order to provide a control interface to the device. 
This lack of interface standards makes programming applications to provide 
access to these devices prohibitive. Yet, there is a growing interest in connecting 
5 devices to the Internet. While Sim Microsystems, Inc/s Jini™ Community 
Process is beginning to address this issue, the lack of well-defined interfaces for 
well-known services is hindering widespread adoption of the Jini™ technology. 
Still, security is a major consideration for programmers of all Internet Aware 
Devices (IADs). While the benefits of direct connection of household and other 
10 devices are revolutionary, the opportunity for unauthorized access greatly 
increases. 

Many of the current approaches to solving this problem use proprietary 
solutions that do not scale or make effective use of the Internet. A workable 
15 solution must provide strong authentication, offer optional encryption of the 
established session, and operate without requiring special permission to 
reconfigure firewalls. Additionally, the solution should not make use of large 
applets that only work on corporate LANs, as some users may access the system 
from low-speed modem and wireless connections. 

20 

Applications for Secure Network Access 

Many software applications suffer from a lack of secure device interfaces. 
Development of applications to access IADs is costly and software life cycles 
25 grow shorter as technology goes through rapid changes. Current architectures 
do not meet the needs of software developers to solve the problems of IAD 
access for desirable applications such as home networks, home automation, and 
process control, to name but a few. While many other applications are 
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susceptible to the same problems, the example of home networks is used here to 
illustrate the problems of using current secure software architectural models. 

5 Home Networks 

The number of users with digital access devices is growing. However, a 
single user may have many such devices spread out over two or more locations 

10 such as home, office, and car. Home networks now provide access to share 
peripherals, computers, and other devices like environmental controls and home 
entertainment systems. Access to a home network is valuable to users away 
from their homes, just as it is to those away from their offices. Many home 
systems contain important data a user many need to access from the office. For 

15 example, leaving that key document on your home system after a long weekend 
of work can be a disaster when you reach the office without it. Similarly, during 
a hectic business day a user may need access to personal data stored in their 
home computer. 

Traditional access architectures do not provide the sort of security 
20 features required to safely and securely access and manage a home network 
remotely. An architecture is needed that can provide controlled access for 
tailored custom services. The current undesirable alternative is to teach all users 
of a home network how to use traditional access mechanisms such as FTP and 
telnet. However, these programs are difficult for non-technical users to master 
25 and fraught with possible damaging errors. Additionally, secure versions of 
these services are not always available on all portable access devices. What is 
needed is a more pragmatic approach - - allowing current devices to access the 
home network through a simple interface, but only after users have given the 
appropriate cryptographic credentials. 



30 
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Problems with Web Applications and IADs 

Web based applications need easy access to devices that require a secure . 
interface, as discussed above. Unfortunately, current technology requires Web 

5 applications to utilize Web browsers to provide a secure interface for 
communication between a user and a Web-based device. However, the primary 
browser technologies available today, Netscape and Internet Explorer, use 
different cryptographic interfaces. Netscape utilizes a scheme called PKCS (RSA 
Labs' Public Key Cryptographic Standard) and Internet Explorer uses a scheme 
10 called CSP (Microsoft's Cryptographic Service Provider.) These two systems 
have different Application Program Interfaces (APIs), though their basic 
functions are similar. This dichotomy requires Web applications to manage their 

' cryptograph interface accordingly. 

15 Other available browsers may add additional complication for Web 

applications developers that want to provide secure access to IADs. Various 
browsers may use Public Key encryption, using public and private keys, or 
possibly use a symmetric encryption scheme that uses a session key. In addition, 
encryption schemes are implemented using different algorithms, provoking 

20 even further complication for applications relying on the Web browser to 
provide a secure interface to an IAD. Cipher modes, salt values, and other 
factors affect the ability of a Web application to interface to any given browser's 
secure interface. 

25 Storing Cr yptographic Keys 

Complications exist for users of Web applications as well. In the present 
technology, Web browsers are responsible for generating and storing keys, 



WO 02/11357 



6 



PCTAUS01/21428 



using the various security modules available to them. Therefore, to use multiple 
browsers, for example Netscape and Internet Explorer, users discover they must 
keep multiple cryptographic keys. When users keep keys at home, at work, and 
on portable devices key management becomes burdensome and security 
5 decreases. Furthermore, keys kept on networked hard disks are subject to 
various forms of hacker attacks. 



The present technology faces many disadvantages, including: 

1. Different security models in Internet Explorer and Netscape 

10 2. No uniform interface to certificate access methods 

3. Redundant storage when both systems are used 

4. Portability of certificates is difficult 

5. Certificate management requires two different interfaces 

6. Other applications cannot easily use certificates 

15 7. Integration with Smart Cards has similar competing models problems 

In the Prior Art, each cryptographic scheme has a unique interface leading 
to a lack of portability. Having duplicate policies for certificates in multiple 
applications complicates the task and decreases the security — thereby providing 
20 multiple points of entry that could lead to the private key is that certificates 
contained. 



25 



ADDITIONAL PACKGROUND 
To better understand the problem solved by the claimed invention, a brief 
description of some prior art technologies follow. 
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General Background Material About Computer Networks 

In order to facilitate an understanding of how computer networks allows 
for the transfer of data a brief discussion about such networks follows. 

Computers and computer networks are used to exchange information in 
5 many fields such as media, commerce, and telecommunications, for example. 
The exchange of information between computers typically occurs between a 
"server application" that provides information or services, and a "client 
application" or device that receives the provided information and services. 
Multiple server applications are sometimes available on a "system server" such as 

10 a single computer server that provides services for multiple clients. 
Alternatively, distributed server systems allow a single client to obtain services 
from applications residing on multiple servers. For example, in current 
distributed server systems, client applications are able to communicate with 
server applications executing on the same computer system or on another 

15 computer system accessible via a network, for instance via the Internet. 

The Internet is a worldwide network of interconnected computers. An 
Internet client computer accesses a computer on the network via an Internet 
provider. An Internet provider is an organization that provides a client 
(computer) with access to the Internet (via analog telephone line or Integrated 
20 Services Digital Network line, for example). A client can, for example, read 
information from, download a file from, or send an electronic mail message to 
another computer /client using the Internet. 

To retrieve a file or service on the Internet, a client must typically search 
for the file or service, make a connection to the computer on which the file or 
25 service is stored, and download the file or access the service. Each of these steps 
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may involve a separate application and access to multiple, dissimilar computer 
systems (e.g., computer systems having operating different systems). The 
World Wide Web (Web) was developed to provide a simpler, more uniform 
means for accessing information on the Internet. 

5 The components of the Web include browser software, network links, 

servers, and Web protocols. The browser software, or browser, is a tool for 
displaying a user-friendly interface (i.e., front-end) that simplifies user access to 
content (information and services) on the Web. Browsers use standard Web 
protocols to access content on remote computers running Web server processes. 

10 A browser allows a user to communicate a request to a Web server without 
having to use the more obscure addressing scheme of the underlying Internet. 
A browser typically provides a graphical user interface (GUI) for displaying 
information and receiving input. Examples of browsers currently available 
include Netscape Navigator and Communicator, and Microsoft Internet 

15 Explorer. 

Web browsers and servers communicate over network links using 
standardized messages formats called protocols. The most common modem 
protocol is the TCP/IP (Transmission Control Protocol /Internet Protocol) 
protocol suite. The protocols are based on the OSI (Open Systems Interconnect) 

20 seven-layered network communication model. Web messages are primarily 
encoded using Hypertext Transport Protocol (HTTP). HTTP instantiates the 
(top) Application layer of the OSI model. Application layer protocols facilitate 
remote access and resource sharing and are supported by the reliable 
communications ensured by the lower layers of the communications model. 

25 Therefore, HTTP simplifies remote access and resource sharing between clients 
and servers while providing reliable messaging on the Web. 
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Information servers maintain the information on the Web and are capable 
of processing client requests. HTTP has communication methods that allow 
clients to request data from a server and send information to the server. 

To submit a request, the client browser contacts the HTTP server and 
5 transmits the request to the HTTP server. The request contains the 
communication method requested for the transaction (e.g., GET an object from 
the server or POST data to an object on the server). The HTTP server responds 
to the client by sending a status of the request and the requested information. 
The connection is then terminated between the client and the HTTP server. 

10 A client request, therefore, consists of establishing a connection between 

the client and the HTTP server, performing the request, and terminating the 
connection. The HTTP server typically does not retain any information about 
the request after the connection has been terminated. That is, a client can make 
several requests of an HTTP server, but each individual request is treated 

15 independent of any other request. 

The Web employs an addressing scheme is that uniquely identifies 
Internet resources (e.g., HTTP server, file, or program) to clients and servers. 
This addressing scheme is called the Uniform Resource Locator (URL). A URL 
represents the Internet address of a resource on the Web. The URL contains 
20 information about the protocol, Internet domain name and addressing port of 
the site on which the server is running. It also identifies the location of the 
resource in the file structure of the server. 

HTTP provides a mechanism of associating a URL address with active 
text. A browser generally displays active text as underlined and color-coded. 
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When activated (by a mouse click, for example) the active text causes the 
browser to send a client request for a resource to the server indicated in the 
text's associated URL address. This mechanism is called a hyperlink. Hyperlinks 
provides the ability to create links within a document to move directly to other 
5 information. A hyperlink can request information stored on the current server 
or information from a remote server. 

If the client requests a file, the HTTP server locates the file and sends it to 
the client. An HTTP server also has the ability to delegate work to gateway 

10 programs. The Common Gateway Interface (CGI) specification defines a 
mechanism by which HTTP servers communicate with gateway programs. A 
gateway program is referenced using a URL. The HTTP server activates the 
program specified in the URL and uses CGI mechanisms to pass program data 
sent by the client to the gateway program. Data is passed from the server to the 

15 gateway program via command-line arguments, standard input, or 
environment variables. The gateway program processes the data and returns its 
response to the server using CGI (via standard output, for example). The server 
forwards the data to the client using the HTTP. 

When a browser displays information to a user it is typically as pages or 
20 documents (referred to as "web pages' 7 ). The document encoding language 
used to define the format for display of a Web page is called Hypertext Markup 
Language (HTML). A sever sends a Web page to a client in HTML format. The 
browser program interprets the HTML and displays the Web page in a format 
based on the control tag information in the HTML. 
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Current network systems provide a way to transfer and display data. 
However, these network systems have left the management of cryptographic 
data to web browsers, application developers, and users to manage without 
standards or coordinated storage methods. The prior art therefore lacks a 
method for managing cryptographic keys in a modern network environment. 
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SUMMARY OF THE INVENTION 

A method and apparatus for managing cryptographic keys using URL 
(Uniform Resource Locator) programming interface (UPI) is described. A user 
5 of public key, symmetric, or other cryptographic scheme must maintain one or 
more keys, a list of trusted certificate authorities, and a database of certificates. 
This collection of distinct items is called a data vault. Current methods of storing 
such information are generally incompatible with each other. Applications, 
including Web browsers, use different standards, algorithms, and formats to 
10 store and manage cryptographic keys. 

The claimed invention provides a single data vault that is accessible by 
any HTTP-capable application. The data vault may reside on any form of 
storage including a disk file, a directory, a Smart Card, a desktop computer, a 

15 handheld device, or other similar devices. A data vault may also extend over 
numerous combinations of storage devices. This architecture uses, in one 
embodiment of the invention, the Java™ language to provide a technology that 
allows users to deploy the data vault interface as a very small protocol (HTTP) 
stack. In one embodiment of the invention, the protocol stack has a core of less 

20 than 100 KB. However, the invention encompasses protocol stacks of both 
larger and smaller size. A minimal stack may be installed on a variety of devices 
to permit secure Internet access to and from any HTTP-capable device. 

One kind of data managed by the data vault includes digital certificates. 
Digital Certificates are generally issued by a Digital Certificate Authority (DCA). 

25 However, there is nothing to prevent the claimed invention from issuing its own 
digital certificates. 
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Single source management of cryptographic data makes connecting 
legacy architectures, home networks, corporate LANs, and Internet^aware 
devices (IADs) to Internet interface units (IIUs) manageable and secure. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a flow diagram of the overall process in one embodiment of 
the claimed invention. 

5 

Figure 2 is a representation of the functions provided by the claimed 
invention. 

Figure 3 represents a smart card reader, in one embodiment of the 
10 claimed invention. 

Figure 4 is a representation of the current technology's approach using 
multiple key stores to generate digital signatures. 

15 Figure 5 shows the method of one embodiment of the claimed invention 

for generating digital signatures. 

Figure 6 shows, in one embodiment of the claimed invention, a session 
that creates a key pair and signs a data item using the claimed invention. 

20. 

Figure 7 is a block diagram of one embodiment of a computer system 
capable of providing a suitable execution environment for an embodiment of the 
invention. 
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DETAILED DESCRIPTION OP THE INVENTION 

The invention is a method and apparatus for managing cryptographic 
keys using Uniform Resource Locator (URL) programming interface (UPI). In 
5 the following description, numerous specific details are set forth to provide a 
more thorough description of embodiments of the invention. It will be 
apparent, however, to one skilled in the art, that the invention may be practiced 
without these specific details. In other instances, well known features have not 
been described in detail so as not to obscure the invention. 

10 

Though discussed herein with respect to the Java™ programming 
language, the invention may be implemented in any environment that supports 
object or data access through references, and that provides information about 
private key URL programming interfaces. Additionally, while one embodiment 
15 of the present invention is described using Java Card™ technology, the 
invention encompasses the use of any device that provides portable storage of 
programmable data. 

IJRL Programming Interface OJPB 

20 

Developing consistent, reliable Web applications that interface to different 
devices— such as home networks, home automation systems, or real-time 
process control devices — can be vastly simplified by treating devices as URLs. 
The URL programming interface (UPI) effectively provides a set of URLs for a 
25 device that is available to any application capable of performing the HTTP 
(HyperText Transfer Protocol.) HTTP has become so universal that in college 
computer courses students are often given as an assignment the creation of an 
HTTP stack. This trend is due to the growing interest in connecting devices to 
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the Internet. Sun Microsystems Laboratories has used the Java™ language to 
develop a technology that allows users to deploy a very small HTTP stacks. 
However, the claimed invention can be practiced using any computer 
programming language and transmission protocol. 

5 

These small HTTP servers can be run on any embedded device or used as 
application servers that are similar to traditional Web servers. Such minimal 
servers provide an integrated presentation and service layer for a device. 
Because a Web server answers URL requests, universal access to devices from 
10 any Internet node is achieved. UPI provides an interface to allow applications, 
including Web applications, to access any device as if the device is a file resident 
on a Web server, if the device can perform the HTTP protocol. 

The UPI architecture, at its core, consists of a series of handlers that are 
15 similar to servlets, but have fewer features. These handlers are mapped to 
1 incorning URL requests. This allows the UPI function on very small devices, such 
as a TESTE board. The UPI supplies handlers for Web services such as file service 
and CGI script execution. Application developers can develop handlers for 
Internet aware devices (IADs) simply by coding a few required methods, such as 
20 init and respond, along with code that understands the applicable device 
grammar. 

The Solution to Multiple Data Vaults 

The claimed invention provides a solution for users required to maintain 
25 multiple data vaults for various applications and network access devices. All 
cryptographic data using the claimed invention may be stored on a single 
Portable Secure Identification Device (PSID.) In one embodiment of the 
invention, the PSID may be implemented using a Smart Card. However, the 
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invention may be practiced using other physical manifestations of the PSID, if 
such devices provide sufficient data storage and are, or can be made to be, 
Internet Aware Devices (IADs.) A Personal Data Assistant (PDA) is another 
example of a PSID that may be an IAD, if it is equipped with a modem or 
5 wireless Web connection. 

Smart Cards 

A Smart Card is a credit card-sized plastic card with an integrated circuit 
10 (IC) inside. The IC contains a microprocessor and memory, which gives Smart 
Cards the ability to process, as well as store more information than was 
previously possible. 

In the case of a Java Card™ platform-based card, Java technology-based 
applications, in the form of byte-codes, are loaded into the memory zone of the 
15 Smart Card's microprocessor where they are run by the Java Virtual Machine. 
The executable code is platform independent so that any card incorporating a 
Java Card™ interpreter can run the same application. 

Multiple Java™ technology-based applications can reside on a single card, 
each allocated to their own secure memory areas to ensure their integrity and 
20 eliminate program tampering, either by individuals or through program 
interference. 

Problems with Smart Cards 

Currently, using Smart Cards on various systems is still subject to errors. 
It is expensive to deploy due to conversion issues and competing browser 
25 security models: There is currently a lack of standards and no clear business 
model to inspire development. Additionally, there is little interoperability 
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between card-based applications developed by various service providers such as 
telecommunications operators, retail vendors, and financial institutions. 

The current concept of a Web browser owning both the Smart Card and 
5 the API interface to the card decreases the utility of a card that only works with a 
browser from company A or company B. There still many applications that 
need to have access to Smart Cards independent of the browser. It would be 
better to have the resource — a Smart Card, in this case — appear as a shared 
resource that is available to all applications on the network, both local and 
10 remote. 

Solving the Smart Card Prob lem with UPI 

In one embodiment, the claimed invention solves this problem by 
creating an architecture utilizes the latest versions of Java™ and Java Card™ and 
15 that is independent of Microsoft and Netscape. The architecture also supports 
non-Java™ Smart Cards. This architecture is built on the concept of UPIs that 
create small Web servers, which in turn are wrapped around physical or logical 
devices. Java Cards™, in one embodiment of the invention, allow applications to 
easily and reliably verify the authority of a user to perform UPI operations. 

20 

As mentioned above, the best current Smart Card solutions on the 
market combines with plethora of methods for accessing the Internet to pose a 
challenge for MIS and IT department. The problems are even more acute in the 
consumer world. The claimed invention's architecture solves this problem by 
25 making the client browser independent; with the addition of the claimed 
invention, UPI has the potential to make Web servers appeared to be equal in 
terms of authenticated access and services. 
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The core concept of UPI involves speaking to a Smart Card and card 
reader combined with an HTTP stack; in other words, the card reader and card 
answer to URLs to provide responses to queries as illustrated in Figure 1 and 
described above: Typically, responses to a Web server request are Web pages, 
5 disk files, or data generated from programs. In one embodiment of the 
invention, data returned to the user comes from the data vault on a Smart Card 
in a Smart Card reader. 

Figure 1 illustrates a flow diagram of the overall process of one 

10 embodiment of the claimed invention. At step 100, a user on a Web accessible 
device invokes a Web browser, or other application capable of generating URL 
requests. At step 110, the user starts an application program that requires secure 
communication. For example, the user may wish to send an email message 
containing a digital signature by which to identify the sender. This scenario will 

15 be used throughout this description as an example of the kind of transaction the 
claimed invention will facilitate. However, the claimed invention may be 
practiced with any application that requires secure communication and/or 
authentication of the user over a network or other intercommunication fabric. 
At step 120 the user invokes a secure transaction, for example commanding the 

20 email message be sent "signed" with a digital signature. The application 
program calls the interface in step 130 by issuing a URL to the invention's UPI to 
initiate a session with the key store that contains the user's cryptographic data. 
The user's key store may be on any IAD that is accessible via UPI at the time the 
user makes the request for the data. At step 140, the application or the user 

25 selects the correct token (IAD and key store) and at step 150, a digital signature is 
produced. In one embodiment of the invention, the IAD is a Smart Card in a 
Smart Card reader equipped with the present invention's UPI. Finally, at step 
160 the signed data is returned to the application for further processing- 
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Figure 2 represents the functions provided by one embodiment of the 
claimed invention. Functions 200 and 205 provide the ability to login or logout a 
user with an established communication session, using the user's PIN (Personal 
5 Identification Number). A PIN is required in addition to access to the user's 
Smart Card to ensure that the user is authorized to access the card. Functions 
210 and 215 are session management functions. A session establishes 
communication with a particular token, in this example a Smart Card. Functions 
220 and 225 provide an application with a list of available tokens and their 

10 attributes. A token may be available or not available; for example, a Smart Card 
removed from a reader may be an unavailable token. The claimed invention 
provides the application the ability to manage objects using functions 230, 235, 
and 240. Objects allow an application to access and manage information 
retrieved from or stored to a token. Functions 245 and 250 control an. object's 

15 attributes. Attributes are label value pairs of information retrieved from or 
stored to a token. Finally, functions 255 and 260 provide decrypt and sign 
functions for using digital signatures. A more detailed explanation of each of 
these functions in one embodiment of the invention follows. 

20 Elements of the UPl 

As an illustration of one embodiment of the invention, handlers for the 
PKCS#11 system used by Netscape are defined as follows. The invention may 
be practiced with or without the following functions, which are provided herein 
25 only as an example of the claimed invention. The invention may be practiced 
using PKCS, any version of PKCS, CSP, or any other cryptographic scheme. 
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getTokenList - this function retrieves a list of tokenlds for all available tokens. 
A tokenld is assigned so that each token available to a given application at a 
given time has a unique tokenld. When a token is no longer available, perhaps a 
card removed from a reader, then the tokenld is removed from the Token List. 

- 5 

getTokenlnfo - this function returns a list of attribute-value pairs describing the 
token associated with tokenld. 

createSession - this function creates a session to be used to communicate with 
10 the specified token and returns a sessionld for that session (unique among all 
open sessions for the calling application at a given time.) Only one operation can 
be active for a given session at a given time. 

closeSession - this function closes the session associated with the sessionld. 

login - this function connects the user to the session associated with sessionld, 
using a PIN. All active sessions associated between this application and this 
token will automatically be logged in (assuming the PIN is correct.) 

20 logout - this function ends the user login with the session identified by 
sessionld. 

createObject - this function creates an object on the token identified, with the 
attributes specified. It returns an objectld associated with the new object. 

deleteObject - this function deletes an object created with createObject above. 
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getAttributes - this function gets the value of the attribute whose identifiers are 
listed in the attribute from the object associated with objectld from the token. 

setAttributes - this function sets the attributes listed in attrs for the object 
5 associated with objectld on the token. 

findObjects - this function finds all objects on the token that match the 
attributes listed in attrs. An array of their objectlds is returned. 

10 generateKeyPair - this function generates a new key pair on the token for the 
mechanismld which indicates the cryptographic scheme to use. The public key, 
when appropriate, is placed in an object with the attributes specified by 
publicKey Attrs. The private key is placed in an object with the attributes 
privateKeyAttrs. An array of the two keys is returned. 

15 

decrypt - this function decrypts the encrypted text passed to it using the 
mechanism identified by mechanismld and the private key stored in the object 
associated with the keyld. Plain text is returned. 

20 sign - this function signs the data using the mechanismld indicated and the 
private key stored in the object associated with keyld. The function returns the 
signature. 

Smart Card Reader Example 
25 An example of a UPI for a Smart Card reader is Provided. The client 

software is called PersonalCard Services, and the server side products are called 
PersonalCard Service Providers. Service Providers provide server 
implementations of code but complete client requests and/or transactions that 
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require server services. PersonalCard Server is a minimal HTTP 1.1 server that 
can respond to URLs of the form: 

http://somehost:somepoii:/Sec^eTokenServices/GetId. 
This is an example of a UPI URL that queries a handler for the operation of the 
5 getid method. The last element in this path is not treated as a file or CGI script, 
but rather as an identifier that allows the handler secured token services to 
dispatch appropriate processing. The getid path component returns the ID of 
Smart Card in the reader. This approach allows non-Java programmers to 
develop Smart Card applications using Java™ script. This approach minimizes 
10 the IT deployment costs because it allows Smart Card readers and Smart Cards 
to be treated as Web servers. The servers can be maintained over the Web using 
HTML and JavaScript macros, or using Java programs and applications. 

Further illustrating the claimed invention, Figure 3 represents a Smart 
15 Card reader, in one embodiment of the invention. The claimed invention 
provides a small HTTP stack that may be run on any IAD that can support a 
Web browser. This stack, along with the UPI interface, provides the device the 
ability to respond to URLs. Figure 3 shows Smart Card reader 300, in one 
embodiment of the invention. URL 310 enters the system via a network 
20 interface, where it is processed by local Web server 320 — a miniature HTTP 
stack program. This interface communicates with traditional Smart Card reader 
interface 340 to store and read data from Smart Card 350 and its Integrated 
Circuit chip 360. 

25 Manag in g User Digital Certificates 

Applications wish to perform many operations using a user's digital 
certificates. Some may include: SSL (Secure Socket Layer) protocol, Signed and 
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Encrypted Email, Form Signing, Single Signon, and Object Signing. 
Furthermore, management of certificates numerous functions must be 
implemented by the application. Certificate management functions include: 
Issuance of Certificates, Certificate and LDAP Directory management, Key 
5 Management, Renewing and Revoking Certificates, and Registration 
Authorities. 



The claimed invention provides access to these certificate operations and 
certificate management functions through a series of URLs that allow application 

10 programs and /or applets to securely interact with certificates stored in the 
invention's data vault. The data vault can be protected with various levels of 
security. The data vault may reside in any location, including a local or remote 
data file, or on an IAD such as a Personal Digital Assistant (PDA) or a Smart 
Card. Some examples of URLs that provide access to a secure portable data 

15 vault are: 



http://localhost:9000/GetCertificate?name="My Email Signer''?verify=''signature'' 
http://localhost:9000/DeleteCerlificate? name="My Email 
Signer"?verify="signature" 

i 

20 http://localhost:9000/NewCertificate? name="My Email Signer"7verify="signature" 

http://localhost:9000/TestCerti£icate? name="My Email Signer''?verify^=''signature'' 

In current technology/ each device manufacturer has a different interface, 
leading to a lack of software portability. The UPI-based approach provides 
25 centralized storage and management with stronger security. Having duplicate 
policies for certificates in multiple applications and multiple locations is 
undesirable because it complicates the task of managing certificates and 
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decreases security by duplication; thereby providing multiple points of entry 
that could lead to discovery of the private keys the certificates contain. 

The claimed invention solves this problem by providing a mechanism to 
5 run a personal certificate server that can support different levels of security and 
is under control of the owner of the certificates rather than control of the Web 
browser. The certificates can be made available to many browsers as well as 
applications and remote operations over the network. Applications may 
perform many operations with the many different types of certificates a user 
10 may own. 

Figure 4 illustrates of the current technology's approach to maintaining 
cryptographic keys using multiple key stores. In this example, a user begins 
with home system 400. Using Web browser 410 the user starts email application 
15 420. Web browser 410 uses the PKGS#11 cryptographic method to create and 
manage cryptographic data. From email application 420> the user wishes to send 
an email message signed with a digital signature. Email application 420 makes 
signature request 450 of Web browser 410 to sign email message 470. The 
message is signed using PKCS#11 interface 430 and cryptographic data stored in 
20 key store 440. The signed email message is returned to email program 420, 
which then sends the message over dialup network connection 480 to Web 
server 490 for further processing. 

Continuing the scenario of Figure 4, the same user now moves to office 
25 system 405. Office system 405 is configured to run email application 425 - a 
different program than the one on home system 400. Email application 425 
makes signature request 455 of CSP interface 435, and received back signed 
message 475 that was encrypted with cryptographic data stored in key store 445. 
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The data in key store 445 and the data in key store 440 are different for two 
reasons. First, the cryptographic schemes used by interfaces 430 and 435 are 
different, and therefore require different key stores. Second, web browser 410 
and web browser 415 each control the email program interface to the 
5 cryptographic system. Meanwhile, the user's cryptographic data is vulnerable 
to attack in two different locations. 

In contrast, Figure 5 shows a method of one embodiment of the claimed 
invention that eliminates the problems of the traditional approach to 

10 cryptographic key management illustrated in Figure 4. In the method of the 
claimed invention, the user's cryptographic data is stored on Internet Aware 
Device (IAD) 550. In one embodiment of the invention IAD 550 is a Smart Card; 
for example a Java Card™. The user may use either home system 500 or office 
system 505 to initiate a secure email message. Email application 510 or 515, 

15 which use different cryptographic schemes as illustrated above, initiates a 
request for a digital signature in the form of URL request 520. Even though both 
applications use different cryptographic schemes they make the same URL call, 
passing different parameters to indicate the cryptographic mechanism to use to 
encode the data. Web server 530 receives each of the requests, and uses UPI 

20 interface 560 to perform the requested encryption, using data stored in data 
vault 570. Signed message 580 is returned as a response to the request by email 
applications 510 and 515. Next, email applications 510 and 515 each send signed 
message 690 back to Web server 530 for delivery. In this example of the claimed 
invention, the user has only one location for cryptographic data, data vault 570. 

25 Data vault 570 is accessible from any network because it can respond to a URL 
via the UPI of the claimed invention. 
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Figure 6 shows, in one embodiment of the invention, the steps to create a 
cryptographic key pair and sign a data item using the claimed invention. At step 
600, the application calls to retrieve a list of available tokens. A data vault 
currently accessible on a network is called a token. In one embodiment of the 
5 invention at step 610, if the desired token is not available, perhaps because a card 
has been removed from the card reader, the application or user must select 
another token. Next, at step 620, the application gets information about the 
selected token, such as its object attributes. To use the token the application 
must create a session, which establishes its connection to the token. This is done 

10 at step 630. Step 640 requires the application to provide the user's PIN or other 
identification required to login to the session for a particular user. In this 
scenario the user wishes to first create a key pair, then use that key pair to sign a 
message. The key pair will be stored on the token for future use. The 
application provides the required information at step 650 and the key pair is 

15 generated. At step 660, the application specifies the cryptographic mechanism, 
key id and data to be signed. Finally, at step 670 the signed data is returned. The 
user's private key is stored in the token's memory for future use. 

Embodiment of Computer Execution Environment (Hardware^ 
20 The claimed invention is a computer system composed of both hardware 

and software. The following detailed description of a general computer 
hardware environment is an example of a system that may be implement the 
claimed invention. This example is illustrative and does not limit the types of 
computers or computer systems that may be used to implement the claimed 
25 invention. 

An embodiment of the invention can be implemented as computer 
software in the form of computer readable code executed on a general-purpose 
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computer such as computer 700 illustrated in Figure 7. A keyboard 710 and 
mouse 711 are coupled to a bi-directional system bus 718. The keyboard and 
mouse are for introducing user input to the computer system and 
communicating that user input to processor 713. Other suitable input devices 
5 may be used in addition to, or in place of, the mouse 711 and keyboard 710. I/O 
(input/output) unit 719 coupled to bi-directional system bus 718 represents such 
I/O elements as a printer, A/V (audio/video) I/O, etc. 

Computer 700 includes a video memory 714, main memory 715 and mass 
10 storage 712, all coupled to bi-directional system bus 718 along with keyboard 
710, mouse 711 and processor 713. The mass storage 712 may include both fixed 
and removable media, such as magnetic, optical or magnetic optical storage 
systems or any other available mass storage technology. Bus 718 may contain, 
for example, address lines for addressing video memory 714 or main memory 
15 715. The system bus 718 also includes, for example, a data bus for transferring 
data between and among the components, such as processor 713, main memory 
715, video memory 714 and mass storage 712. Alternatively, multiplex 
data/address lines may be used instead of separate data and address lines. 

20 In one embodiment of the invention, the processor 713 is a 

microprocessor manufactured by Motorola, such as the 680X0 processor or a 
microprocessor manufactured by Intel, such as the 80X86, or Pentium processor, 
or a SPARC™ microprocessor from Sun Microsystems, Inc. However, any other 
suitable microprocessor or microcomputer may be utilized. Main memory 715 is 

25 comprised of dynamic random access memory (DRAM). Video memory 714 is a 
dual-ported video random access memory. One port of the video memory 714 
is coupled to video amplifier 716. The video amplifier 716 is used to drive the 
cathode ray tube (CRT) raster monitor 717. Video amplifier 716 is well known in 
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the art and may be implemented by any suitable apparatus. This circuitry 
converts pixel data stored in video memory 714 to a raster signal suitable for use 
by monitor 717. Monitor 717 is a type of monitor suitable for displaying graphic 
images. Alternatively, the video memory could be used to drive a flat panel or 
5 liquid crystal display (LCD), or any other suitable data presentation device. 

Computer 700 may also include a communication interface 720 coupled to 
bus 718. Communication interface 720 provides a two-way data commimication 
coupling via a network link 721 to a local network 722. For example, if 

10 communication interface 720 is an integrated services digital network (ISDN) 
card or a modem, commimication interface 720 provides a data communication 
connection to the corresponding type of telephone line, which comprises part of 
network link 721. If commimication interface 720 is a local area network (LAN) 
card, communication interface 720 provides a data communication connection 

15 via network link 721 to a compatible LAN. Communication interface 720 could 
also be a cable modem or wireless interface. In any such implementation, 
communication interface 720 sends and receives electrical, electromagnetic or 
optical signals that carry digital data streams representing various types of 
information. 

20 

Network link 721 typically provides data communication through one or 
more networks to other data devices. For example, network link 721 may 
provide a connection through local network 722 to local server computer 723 or 
to data equipment operated by an Internet Service Provider (ISP) 724. ISP 724 in 
25 turn provides data communication services through the worldwide packet data 
communication network now commonly referred to as the "Internet" 725. Local 
network 722 and Internet 725 both use electrical, electromagnetic or optical 
signals that carry digital data streams. The signals through the various networks 
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and the signals on network link 721 and through communication interface 720, 
which carry the digital data to and from computer 700, are exemplary forms of 
carrier waves transporting the information. 

5 Computer 700 can send messages and receive data, including program 

code, through the network(s), network link 721, and communication interface 
720. In the Internet example, remote server computer 726 might transmit a 
requested code for an application program through Internet 725, ISP 724, local 
network 722 and communication interface 720. 

10 

The received code may be executed by processor 713 as it is received, 
and/or stored in mass storage 712, or other non-volatile storage for later 
execution. In this manner, computer 700 may obtain application code in the 
form of a carrier wave. In accordance with an embodiment of the invention, an 
15 example of such a downloaded application is the apparatus for debugging a 
virtual machine described herein. 

Application code may be embodied in any form of computer program 
product. A computer program product comprises a medium configured to store 
20 or transport computer readable code or data, or in which computer readable 
code or data may be embedded. Some examples of computer program products 
are CD-ROM disks, ROM cards, floppy disks, magnetic tapes, computer hard 
drives, servers on a network, and carrier waves. 



25 



The computer systems described above are for purposes of example only. 
An embodiment of the invention may be implemented in any type of computer 
system or programming or processing environment, including embedded 
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devices (e.g., Web phones, etc.), wireless devices, and "thin" client processing 

environments (e.g., network computers) that support a virtual machine. 

• ■ . . . ' ■ • 

Thus, a method and apparatus for managing cryptographic keys using 
5 Uniform Resource Locator (URL) programming interface (UPI) have been 

described in conjunction with one or more specific embodiments. The invention 
is defined by the claims and their full scope of equivalent. 
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CLAIMS 

1. A method in a computer system comprising: 
storing cryptographic data on a portable device; 

5 accessing said cryptographic data through an addressable interface. 

2. The method of claim 1 wherein said cryptographic data comprises a 
session key. 

10 3. The method of claim 1 wherein said cryptographic data comprises a public 
key. 

4. The method of claim 1 wherein said cryptographic data comprises a 
private key. 

15 

5. The method of claim 1 wherein said cryptographic data comprises at least 
one digital certificate. 

6. The method of claim 1 wherein said addressable interface operates over 
20 an interconnection fabric. 

7. The method of claim 1 wherein said storing further comprising: 
providing a protocol stack to process requests for said cryptographic data; 
wherein said portable device comprises an internet aware device. 

8. The method of claim 7 further comprising: 

retrieving said cryptographic data if valid user credentials are presented. 
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9. The method of claim 8 further comprising: , 

generating a digital signature based on said cryptographic data. 

10. The method of claim 7 wherein said protocol stack comprises: 
5 providing a secure communication session; 

encrypting data in said secure communication session using at least one 
cryptographic scheme; 

decrypting data in said secure communication session using said at least 
one cryptographic scheme; 
10 generating cryptographic keys in said secure communication session 

using at least one cryptographic scheme. 

11. An apparatus comprising: 

an internet interface unit configured to utilize the HTTP protocol; 
15 a web server; 

an internet aware device comprising a processing unit and a memory; 
wherein said internet aware device can access a data vault. 

12. The apparatus of claim 11 wherein said data vault comprises at least one 
20 cryptographic key. 

13. The apparatus of claim 11 wherein said data vault comprises at least one 
digital certificate. 
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14. A computer program product comprising: 

computer readable program code configured to cause a computer to store 
cryptographic data on a portable device; 

computer readable program code configured to cause a computer to 
5 access said cryptographic data through an addressable interface. 

15. The computer program product of claim 14 wherein said cryptographic 
data comprises a session key. 

10 16. The computer program product of claim 14 wherein said cryptographic 
data comprises a public key. 

17. The computer program product of claim 14 wherein said cryptographic 
data comprises a private key. 

15 

18. The computer program product of claim 14 wherein said cryptographic 
data comprises at least one digital certificate. 

19. The computer program product of claim 14 wherein said addressable 
20 interface operates over an interconnection fabric. 

20. The computer program product of claim 14 further comprising: 
computer readable program code configured to cause a computer to 

provide a protocol stack to process requests for said cryptographic data; 
25 wherein said portable device comprises an internet aware device. 
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21. The computer program product of claim 20 further comprising: 

computer readable program code configured to cause a computer to 
retrieve said cryptographic data if valid user credentials are presented. 

5 22. The computer program product of claim 21 further comprising: 

computer readable program code configured to cause a computer to 
generate a digital signature based on said cryptographic data. 

23. The computer program product of claim 20 wherein the functions of said 
10 protocol stack comprise: 

computer readable program code configured to cause a computer to 
provide a secure communication session; 

computer readable program code configured to cause a computer to 
encrypt data in said secure communication session using said at least one 
15 cryptographic scheme; 

computer readable program code configured to cause a computer to 
decrypt data in said secure communication session using at least one 
cryptographic scheme; 

computer readable program code configured to cause a computer to 
20 generate cryptographic keys in said secure communication session using at least 
one cryptographic scheme. 
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